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SYSTEM AND METHOD FOR IMPLEMENTING A SCHEMA OBJECT 
MODEL IN APPLICATION INTEGRATION 

CLAIM OF PRIORITY 

This application claims priority to the following applications each of 
which is hereby incorporated herein by reference: 

5 

U.S. Provisional Patent Application No. 60/347,919, filed October 
18. 2001. entitled "APPLICATION VIEW". 

U.S. Provisional Patent Application No. 60/347,901 , filed Octoberl 8, 
10 2001 , entitled "EVENT ADAPTER". 

U.S. Patent Application No. entitled "APPLICATION VIEW 

COMPONENT FOR SYSTEM INTEGRATION," by Mitch Upton, filed 
October 15, 2002. 

15 

U.S. Patent Application No. entitled "SYSTEM AND 

METHOD FOR INVOKING BUSINESS FUNCTIONALITY FOR A 
WORKFLOW," by Mitch Upton, filed October 15, 2002. 

20 U.S. Patent Application No. entitled "SYSTEM AND 

METHOD FOR IMPLEMENTING AN EVENT ADAPTER." by Mitch Upton, 
filed October 15, 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

25 METHODUSINGACONNECTORARCHITECTUREFORAPPLICATION 
INTEGRATION," by Mitch Upton, filed October 1 5, 2002. 
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U.S. Patent Application No. entitled "SYSTEIVI AND 

METHOD FOR IMPLEIVIENTING A SCHEMA OBJECT MODEL IN 
APPLICATION INTEGRATION." by Mitch Upton, filed October 15. 2002. 

5 U.S. Patent Application No. entitled "SYSTEM AND 

METHOD UTILIZING AN INTERFACE COMPONENT TO QUERY A 
DOCUMENT," by Mitch Upton, filed October 15. 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

10 METHOD USING ASYNCHRONOUS MESSAGING FOR APPLICATION 

INTEGRATION," by Mitch Upton, filed October 1 5, 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

METHOD FOR IMPLEMENTING A SERVICE ADAPTER." by Mitch Upton, 
15 filed October 15, 2002. 

COPYRIGHT NOTICE 
A portion of the disclosure of this patent document contains material 
which is subject to copyright protection. The copyright owner has no 
20 objection to the facsimile reproduction by anyone of the patent document 

of the patent disclosure, as it appears in the Patent and Trademark Office 
patent file or records, but othenvise reserves all copyright rights 
whatsoever. 
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The following applications are cross-referenced and incorporated 
herein by reference: 
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U.S. Patent Application No. entitled "APPLICATION VIEW 

COMPONENT FOR SYSTEM INTEGRATION," by Mitch Upton, filed 
October 15, 2002. 

5 U.S. Patent Application No. entitled "SYSTEM AND 

METHOD FOR PROVIDING A JAVA INTERFACE TO AN APPLICATION 
VIEW COMPONENT," by Mitch Upton, filed October 15. 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

10 METHOD FOR INVOKING BUSINESS FUNCTIONALITY FOR A 

WORKFLOW." by Mitch Upton, filed October 15, 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

METHOD FOR USING WEB SERVICES WITH AN ENTERPRISE 
15 SYSTEM, " by Mitch Upton, filed October 15, 2002. 

U.S. Patent Application No. entitled '"SYSTEM AND 

METHOD FOR IMPLEMENTING AN EVENT ADAPTER," by Mitch Upton, 
filed October 15, 2002. 

20 

U.S. Patent Application No. entitled "SYSTEM AND 

METHOD USING A CONNECTOR ARCHITECTURE FOR APPLICATION 
INTEGRATION," by Mitch Upton, filed October 15, 2002. 

25 U.S. Patent Application No. entitled "SYSTEM AND 

METHOD UTILIZING AN INTERFACE COMPONENT TO QUERY A 
DOCUMENT," by Mitch Upton, filed October 1 5, 2002. 
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U.S. Patent Application No. entitled "SYSTEM AND 

METHOD USING ASYNCHRONOUS MESSAGING FOR APPLICATION 
INTEGRATION," by Mitch Upton, filed October 15, 2002. 

5 U.S. Patent Application No. entitled "SYSTEMS AND 

METHODS FOR INTEGRATION ADAPTER SECURITY." by Mitch Upton, 
filed October 15, 2002. 

U.S. Patent Application No. entitled "SYSTEM AND 

1 0 METHOD FOR IMPLEMENTING A SERVICE ADAPTER." by Mitch Upton, 

filed October 15.2002. 

FIFLD OF THE INVENTION 
The invention relates generally to systems and methods for 
1 5 integrating applications. 

BACKGROUND OF THE INVENTION 
E-commerce has become a major driving factor in the new 
economy. To be successful in the long-term, e-commerce will require 

20 many companies to engage in cross-enterprise collaborations. To achieve 

cross-enterprise integration, a company must first integrate its internal 
applications. Using existing technology and tools, application integration 
can be an expensive proposition. No integration solution exists that is easy 
to use, affordable, and based on industry standards. Neither does a 

25 solution exist that is based on an industry standard infrastructure, has 

universal connectivity, is capable of massive scalability, and has accessible 
business process tools. 
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Application Integration to this point has been very inward-focused. 
Many existing integration systems have not focused on integrating 
applications between enterprises. Even when integration solutions were 
used for cross-enterprise integration, the solutions were still narrowly 

5 focused and aimed at vertical markets. This inward focus did little to help 

companies field external business-to-consumer and business-to-business 
applications, such as applications that can utilize the Internet to generate 
revenue and reduce costs. The requirement for Internet-enabled 
applications led to the rise of the application server market. To date, 

10 application servers have primarily been used to host external applications 

targeted at customers and partners. Application servers are themselves 
packaged applications that, instead of solving a specific problem, are 
general-purpose platforms that host vertical solutions. 

15 The first attempts at application integration were primarily focused 

on low-level implementation details such as the format of the data, the byte 
ordering between machines, and character encoding. The focus on low- 
level data formats was necessary because, for the first generation of 
application integration solutions, there were no widely adopted standards 

20 for data encoding that could be deployed across multiple vertical 

applications. 

The traditional approach involved connecting individual systems to, 
in effect, hardwire the systems together. This approach can be complex. 
25 as connecting different systems can require an intimate, low-level 

knowledge of the proprietary technologies of multiple systems. 

Present integration systems, which have moved away from 
"hardwiring" systems together, still suffer from a lack of standards. Each 
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integration vendor typically provides a proprietary solution for application 
integration, message transformation, message formats, message transport, 
and routing. Not one of these systems to date has achieved significant 
market share to enable its technologies to become the de-facto standard. 
5 This lack of standards has given packaged application vendors little 

incentive to integrate these systems with their. Further, each of these 
integration systems or servers has its own proprietary API. such that 
packaged application vendors cannot leverage development beyond a 
single Integration server This fragmentation of the integration market has 
10 provided little financial incentive for third parties. 

SUMMARY OF THE INVENTION 
Systems and methods in accordance with embodiments of the 
present invention allow communication to be passed between components, 

1 5 such as an enterprise system and a client application, by taking advantage 

of schemes. A schema can be used to ensure that a communication, such 
as a request or response, is in the proper format for one of the 
components. For instance, metadata can be received from an enterprise 
system in response to a request from a client application. That metadata 

20 can be transformed to a response document that conforms to a schema. 

The document can be validated against the schema and passed on to the 
client application. 

Other features, aspects, and objects of the invention can be 
25 obtained from a review of the specification, the figures, and the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 is a diagram of an integration system that can be used in 
accordance with one embodiment of the present invention. 
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Figure 2 is a diagram of an integration system that can be used in 
accordance with another embodiment of the present invention. 

Figure 3 shows a method that can be used with the systems of 
5 Figures 1 and 2. 

Figure 4 is a flowchart showing a process that can be used with the 
systems of Figures 1 and 2. 

10 DETAiLED DESCRIPTION OF THE INVENTION 

Application integration components can be used to integrate a 
variety of applications and systems, such as Enterprise Information 
Systems (EISs). Information technology (IT) organizations typically utilize 
several highly-specialized applications. Without a common integration 

1 5 platform to facilitate application-level integration, these applications cannot 

be integrated without extensive, highly-specialized development efforts. 

Application integration can utilize adapters to establish an 
enterprise-wide, united frameworl< for integrating any current or future 
20 application. Adapters can simplify integration efforts by allowing each 

application to be integrated with an application server, instead of requiring 
that each application being integrated with every other application. 

The development and widespread acceptance of standards such as 
25 the Java 2 Platform. Enterprise Edition (J2EE)from Sun Microsystems, Inc. 

of Santa Clara, CA, as well as the extensible Markup Language (XML), 
has laid the groundworlc for a standardized approach to the development 
of these adapters. Perhaps the most significant of these standards for 
application integration is the J2EE Connector architecture. The J2EE 
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Connector architecture provides a standardized approach for the 
development of adapters for alt types of applications, from legacy 
mainframe applications, such as CICS from IBM, to packaged applications 
such as PeopleSoft, Siebel, and SAP. The adoption of such standards 
5 enables businesses to develop adapters that work on any J2EE-compliant 

application server, for example. 

Integration Architecture 

Application integration can build on this standardized approach in 
10 an application integration framework by providing a standards-based 

architecture for hosting J2EE Connector architecture-based adapters. 
Developers can build J2EE Connector architecture-compliant adapters and 
deploy these adapters, in the integration framework, to connect enterprise 
applications to an application server. 

15 

These adapters can be used to define business-focused interfaces 
to an EIS, the interfaces referred to herein as "application views" of the 
respective adapters. An application view can provide a simple, self- 
describing, consistent interface to services and events in an application. 

20 Application views can make use of an adapter for an EIS, making it 

possible to expose existing information systems as business services. 
Unlike adapters, however, an application view does not require users to 
have intimate knowledge of the EIS or the client interface for that EIS, such 
that non-programmers or technical analysts can use application views. An 

25 application view can provide a business-oriented way for business analysts 

to access enterprise data without worrying about the programmatic details 
defined in an adapter. These same users may be otherwise unable to use 
an adapter directly, due to a lack of familiarity with the EIS. 
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An application integration component directed at enterprise 
application integration can have several primary aspects. If the 
functionality of an EIS such as a PeopleSoft system or an SAP system is 
to be invoked, an implementation of the J2EE Connector Architecture can 
5 be used. If something occurs inside an EIS system, such as a trigger going 

off, an event can be generated. This event may, In some embodiments, 
need to be communicated to an external application. An event architecture 
in an application integration component can handle this communication. 

10 Application Views 

An application view can provide significant value to an application 
integration component. An application view can abstract away much of the 
complexity in dealing with an application, such as a backend EIS system. 
Application views can also simplify the way in which adapters are 

15 accessed. Application views can provide a layer of abstraction, for 

example, between an adapter and the EIS functions exposed by that 
adapter. Instead of accessing an EIS by direct programming a user can 
simply: edit an adapter's application views, create new application views, 
or delete any obsolete application view(s). A layer of abstraction formed by 

20 application views can help non-programmers maintain the services and 

events exposed by an adapter. Each application view can be specific to a 
single adapter, and can define a set of business functions on that adapter's 
EIS. After an adapter is created, a Web-based interface for the adapter 
can be used to define application views. 

25 

If an application view is used as a primary user interface for an 
adapter, a number of features can be included that are not commonly 
found in existing enterprise application integration technologies. Application 
views can, for example, use XML as a common language among 
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applications. Service and event definitions can be used to expose 
application capabilities. XML schemas can be used to define the data for 
services and events. Bidirectional communication can also be supported 
in adapters. 

An application view can be an integral part of an integration 
framework. An application view can provide a view of the application 
capabilities exposed by an adapter that a user can customize to meet 
specific needs. A user can tailor an application view, for example, for a 
specific business purpose. As a result, the application view can provide an 
effective alternative to the "one size fits all" approach that many 
applications provide for the design of a client interface. An application view 
can be defined for only the business or other capabilities that are 
applicable for a specific purpose. The capabilities can be customized such 
as by naming, describing, and defining the data requirements. 

In one example, shown in Figure 1, adapters 106, 108, 110 can be 
developed that allow a client application 100 to communicate with an 
Enterprise Information System 104 through the use of an application view 
20 102. A developer can begin by coding an adapter that exposes the 

functionality in the enterprise application that accesses enterprise data. 
The functionality the adapter exposes could, for example, update records 
in a database using SQL statements, or could request information from an 
SAP system using its BAPI or IDOC interfaces. A business analyst. 
25 working with the developer, can then define an application view of the 

adapter using an application view interface. 

Another example of a system is shown in Figure 2. In this figure, 
a client application 200 can communicate with an EIS 218 through an 
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integration server 202. The integration server can be, for example, a web 
server or application server 202, and can be included in a cluster or 
integration system, represented here by the dotted line. The integration 
server can include an application view component 204 and a resource 
5 adapter 206 for the EIS 218. An XML schema API 208. useful in 

generating an XML schema 214 for the client application 200 using the 
schema object model 212 can be included in the integration server 202. 
An XML document API 210, which can provide an interface to an XML 
document using an IDocument component 216 such as IDoc class 
10 libraries, for example, can also be included on the integration server 202. 

The schema object model 212, XML schema 214, and IDocument 
component 216 do not need to be contained on the integration sen/er 202, 
but should be accessible to the integration server. 

15 An application view is an object, which can be implemented in one 

embodiment as a stateless session JavaBean. There can be a Java 
interface to the application view for the client application. A Java 
application can be custom coded to use that object, such as by passing 
XML in and receiving XML back. In addition, a business process manager 

20 component can be included that allows process engineers to define 

workflows, and allows application views to be invoked as business 
services. In a workflow, a callout can be made to an EIS to get information 
such as a customer's credit record. The fact that the application view is a 
Java object or enterprise JavaBean can be hidden from the process and 

25 designer. 

A web services interface can also be used with an application view. 
A protocol such as SOAP can be used to invoke a web service. Another 
protocol that may be used includes UDDI, a platform-independent, open 
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framework for describing services, discovering businesses, and integrating 
business services using the Internet. A WSDL protocol can also be used, 
whicli is an XI\4L format for describing networl< services . A web services 
layer can be provided on top of tlie application view so that any application 
view can be invoked as a web service. 

In application integration, new application views can be hot- 
deployed against an existing EIS through a web-based interface. An 
application view is hot-deployed when it is deployed with the system 
running, without restarting the destination server. A new customer 
management tool for SAP, for example, can also be defined through a web 
browser. 

Integration Framework 

Application integration can utilize an integration framework, which 
can provide a systematic, standards-based architecture for hosting 
application views. Features of such a framework can include application 
views for exposing application functions and design-time graphical user 
interfaces (GUIs), such as web-based interfaces that can be used for 
creating application views. The integration framework utilizes adapters, 
instead of "hardwiring" enterprise systems together. Once an adapter is 
deployed for an EIS, other components and applications can use that 
adapter to access data on the EIS. 

A framework in accordance with one embodiment of the present 
invention relies on XML as the standard format for messages. XML 
includes XSLT, a standard for transforming XML documents into other XML 
documents. XSLT is designed for use as part of XSL, which is a stylesheet 
language for XML. In XSLT, an XML document is used to specify the 
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operations to perform on a class of XML documents in order to transform 
the documents' structure and content. An XSLT transformation can malce 
use of any of the operations built into the Java programming language, or 
can make use of custom operations written either in Java or in native code. 
An integration framework allows a business process to invoke an XSLT 
engine in order to transform XML messages. 

An integration framework can also rely on standards for transporting 
messages such as Java Message Service (JMS) and HTTPS. JMS is a 
standard API for interfacing with message transport systems. Using JMS, 
a framework can utilize any message transport mechanism that provides 
a JMS interface. The J2EE Connector architecture standard does not 
specify a message transport mechanism, but an application integration 
framework can specify such a transport mechanism. 

An integration framework can be based on an existing standard 
infrastructure, such as an application sen/er that supports J2EE. JMS, and 
the J2EE Connector architecture. Using such a standard infrastmcture 
also provides for high availability and scalability, such as by clustering and 
resource pooling. The framework can provide for universal connectivity by 
enabling the construction of XML-based application adapters that can 
connect to any legacy and packaged application. An adapter development 
kit can be used to allow users such as customers, system integrators, and 
packaged application vendors to quickly develop J2EE connector 
architecture-compliant and integration framework-based adapters. The 
framework can utilize XML, which means that the same data format can be 
used for both within- and between-enterprise integration, since many e- 
commerce systems use XML as the standard message format. 
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An integration framework can also utilize a business-process engine 
to allow non-programmers to graphically construct and maintain business 
processes. An integration framework can implement a common model on 
top of the J2EE Connector architecture that is focused on business-level 
5 concepts. This model, which can consist of XML-encoded events and 

services, allows the management of a consistent integration environment, 
regardless of the interface required between adapters and their target 
applications. The business processes can react to events generated by 
applications, and they can invoke an application's functionality via services 
10 that are exposed by an application adapter. 

Adapter Development 

XML development tools, such as may be included in an ADK, can 
be considered part of a metadata support layer for a design-time 

1 5 framework. These tools, which can comprise an XML Toolkit, can include 

an XML schema API. which can be characterized by a Schema Object 
Model (SOM). This API can be used to programmatically build XML 
schemas. An adapter can call an enterprise system or EIS for specific 
request and response metadata, which can then be programmatically 

20 transformed into an XML schema. The SOM is a set of tools that can 

extract many of the common details, such as syntactical complexities of 
XML schema operations so that a user can focus on its more fundamental 
aspects. Another tool that can be included is an XML Document API, 
which can be characterized by I Document. This API can provide an x-path 

25 interface to a document object model (DOM) document. 

An IDocument. which can facilitate XML input and output from the 
CCI layer in an adapter, is a higher-order wrapper around the W3C 
Document Object Model (DOM). The primary value-add of the IDocument 
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interface is that it provides an XPath interface to elements in an XML 
docunnent. In other words, I Document objects are queryable and updatable 
using XPath strings. For example, the following XML document describes 
a person named "Bob" and some of the details about "Bob." 

5 < Person name = "Bob" > 

<Home squareFeet="2000"/> 
< Family > 

< Chi Id name* "Jimmy "> 

<Stats genders "male" hair="brovm" eyes="blue"/> 
10 </Child> 

<Child name= "Susie" > 

<:Stats gender^" female" hair^ "blonde" eyes= "brown"/ > 
</Child> 
</Family> 
15 </Person> 

By using IDocument, Jimmy's hair color can be retrieved using code 
such as: 

System.out.prlntlnfJimm/s hair color: " 
20 person.getStririgFrom{7/Person[@name=\"Bobr]/Family/Chlld 
[@name=\"Jrmmy\"]/Stats/@halr"); 

On the other hand, if DOM is used it would be necessary to use 
code such as: 

25 String strJimmysHairColor = null; 

org .w3c.dom. Element root = doc.getDocumentElement(); 
If {root.getTagName().equals(-Person") && 
root.getAttributername").equals("Bob"){ 
org.w3c.dom.NodeLlst list = root. 
30 getElementsByTagName("Family"); 
if (llst.getLengthO > 0) { 
org,w3c.dom. Element family = (org.w3c.dom. 
Element)list.item(0); 

35 org.w3c.dom.NodeList childList = family.getElementsByTagNamef Child"); 

for (Int i=0; i < childList.getLength{); { 
org.w3c.dom. Element child = childListjtem(i); 

if (child.getAttrlbutername").equals("Jimmy")) { 
org.wSc.dom.NodeList statsList = 
40 child.getElementsByTagName("Stats"); 

if (statsList.getLengthO > 0) { 
org.w3c.dom. Element stats = statsList.item(O); 
StrJimmysHairColor = stats.getAttribute("hair"); 

} 

45 } 
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} 

} 

} 

5 XCCI Design Pattern 

A common design pattern that emerges when using an XCCI 
approach is to support the definition of services in an interaction 
implementation. In other words, a javax.resource.cci. Interaction 
implementation for an adapter can allow a client program to retrieve 

1 0 metadata from an underlying EIS in order to define an Integration service. 

Specifically, this means that the interaction must be able to generate the 
request and response XML schemas and additional metadata for a service. 
Additionally, the Interaction could also allow a client program to browse a 
catalog of functions provided by the EIS. This approach facilitates a thin 

1 5 client architecture for an adapter. 

Data Transformation Method 

Data transformation is the process of taking data from an enterprise 
system and transforming the data into an XML schema that can be read by 
20 the application server. For each event, a schema can define what the XML 

output looks like. This can accomplished by using SOM and IDocument 
class libraries. 

The following sample code listings show one data transformation 
25 sequence. The following code can be used to transform data from an EIS 

into an XML schema: 

SOMSchema schema = new SOMSchema(); 
SOMEIement root = new SOMEIementrSENDINPUr); 
SOMComplexType mailType = new SOMComplexType(); 
30 root.setType(rriailType); 

SOMSequence sequence = mailType.addSequenceO; 
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SOMEIement to = new SOMEIement("TO"); 
to.setMjnOccurs("1 
to.setMaxOccurs("unbounded"); 
sequence.add(to); 
5 SOMEIement from = new SOMEIementCFROM-); 

from.setMlnOccurs("1"); 
from.setMaxOccurs("1"); 
sequence. add(from); 

SOMEIement cc = new SOMEIement("CC"); 
1 0 cc.setMlnOccurs("1 "); 

cc.setMaxOccurs("unbounded"); 
sequence. add(cc); 

SOMEIement bcc = new SOMEIementf BCC"); 
bcc.setMinOccurs(" 1 "); 
1 5 lxx:.setMaxOccurs("unbounded"): 
sequence.add(bcc); 

SOMEIement subject = new SOMEIementrSUBJECT"); 
subject.setMinOccurs("1"); 
subject.setMaxOccurs("1 "); 
20 sequence.add(bcc); 

SOMEIement body = new SOMEIement("BODY"); 
if (template == null) 

{ body.setMinOccursC'r): 
body.setMaxOccursf 1 "); 
25 }e1se 

{ Iterator iter = template.getTags(); 
if (iter.hasNextO) 

{ SOMComplexType bodyComplex = new SOMComplexType(); 
body.setType(bodyComplex); 
30 SOMAN all = new SOMAII(); 

while (Iter.hasNextO) 

{ SOMEIement eNew = new SOMEIement((String)iter.next()); 

all.add(eNew); 
}//endwhile 

35 bodyComplex.setGroup(all); 

}//endif 
}//endlf 
sequence.add(body); 
schema.addElement(root); 



40 



The following example shows an XML schema created by the above 



code: 



<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 
<xsd:element name="SENDINPUT"> 
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<xsd:complexType> 
<xsd:sequence> 

<xsd:e!ement name-TO" maxOccurs-'unbounded" 

type="xsd: string7> 
<xsd:element name=**FROM" type="xsd:string7> 
<xsd:element name- 'CC" maxOccurs="unbounded" 

type="xsd:strlng7> 
<xsd:element name="BCC'' maxOccurs= 

"unbounded" type= "xsd:string7> 
<xsd:element name="BCC" maxOccurs="unbounded" 

type="xsd:string7> 
<xsd:element name="BODY" type="xsd:string7> 
</xsd:sequence> 
</xsd:complexType> 
</xsd:element> 



The following example shows a valid XML document created by the 
schema shown above: 

</xsd:schenna> 
20 <?xml verslon="1 .0"?> 

<!DOCTYPE SENDINPUT> 
<SENDINPUT> 
<T0/> 
<FROM/> 
25 <CC/> 

<BCC/> 
<BCC/> 
<BODY/> 

</SENDINPUT> <xsd:schema xmlns:xsd = 
30 "http://wvvw.w3.org/2001/XMLSchenria"> 



-18- 



10 



wo 03/034228 



PCT/US02/33090 



The adapter can be tested and then deployed. An adapter can be 
deployed manually, or through a tool such as a server or Integration 
console. 

XML Toolkit 

An XML toolkit can be utilized that can help to develop valid XML 
documents to transmit information from a resource or enterprise system to 
an application on the other side of an adapter. The toolkit can incorporate 
many of the operations required for XML manipulation into a single 
location, relieving the user of these often tedious chores. 

An XML toolkit can be comprised primarily of two Java packages, 
such as a com.document package and a com. schema package. These 
packages can include complete Javadocs for each class, interface, and 
method. 

IDOC 

An IDocument, or IDoc, is a container that combines the W3C 
Document Object Model (DOM) with an XPath interface to elements in an 
XML document. This combination can make IDocument objects queryable 
and updatable simply by using XPath strings. These strings can eliminate 
the need to parse through an entire XML document to find specific 
information by allowing a user to specify just the elements the user wants 
to query and then returning the values of those queries. 

An IDocument can be a public interface that represents an XML 
document An IDocument can provide a document type name, which can 
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be used to refer to a description of its structure and usage. In addition, 
(Documents can be mutable, and can provide methods for retrieving, 
rnodifying, adding, and removing data elements. All I Document objects can 
be queryable, and can be updatable such as by using XPath strings. Also. 
•Document instances can be serializable to, and un-seriallzablefrom, XML. 
I Document objects can implement a Java interface such as 
java.io.Serializable. 

The default representation of the document represented by an 
■Document can be a W3C DOM instance, such as org.wSc.dom.Document. 
The IDocument may at times be in an unparsed state. This can happen if 
the IDocument was explicitly constructed this way, by using a method such 
as DocumentFactory.createDocument(String, boolean), forexample, where 
the boolean argument is 'taie.* The internal state of an IDocument can be 
determined using a method such as isParsed(). If this returns true, then the 
content of the document has been parsed into a DOM. If 'false' is 
returned, the IDocument may contain just the raw XML text. 

In cases where an IDocument is in an unparsed state, the content 
can be parsed using a SAX parsing scheme that allows a user to build an 
in-memory representation of the document that is not DOM. A method such 
as fromXML(ContentHandler) can be used for this purpose, allowing a user 
to parse the document's content manually using an interface such as an 
implementation of a ContentHandler interface. A user could achieve similar 
results by getting the raw content from the IDocument and 
creating/invoking a custom SAX parser. 
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I Document can simplify tlie code necessary to query and find 
information in a document, as opposed to code sucfi as DOIVI code. For 
example, the following XML document describes a person named "Bob" 
and some of the details about "Bob": 

< Person names " Bob "> 

<Home squareFeet="2000'*/> 
< Family > 

<Child name = "Jimmy" > 

<Stats sex="male" hair="brown" eyes="blue"/> 
</Child> 

< Chi Id name="Susie"> 

<Stats sex="female" hair="blonde" eyes= "brown" /> 
</Child> 
</Family> 
</Person> 

In order to retrieve Jimmy's hair color from the <child> element by 
using I Document, an XPath string can be created that seeks exactly that 
information, as shown the following IDocument data retrieval code sample: 
System.out.printIn("Jimmy's hair color: " + person.getStringFrom 
(7/Person[@name=\"BobVVFamily/Chlld[@name=rjimmyV']/Stats/@haiO 

Schema Object Model fSOM) 

A schema object model (SOM) is an Interface useful for 
programmatically building schemas, such as XML schemes, SOM can 
comprise a set of tools that can extract and validate many of the common 
details, such as syntactical complexities of schema, so that a user can 
focus on more fundamental aspects. As shown in the method of Figure 3, 
for example, an XML schema can be created for a client application using 
a schema object model 300. A component such as a resource adapter can 
call into an EIS for specific request/response metadata. Metadata can be 
received from the EIS in response to the request 302, which can be 
programmatically transformed Into an XML document that conforms to the 
XML schema for the client application 304. At least a portion of the XML 
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document can be validated against the XIVIL schema for the client 
application 306. An {Document interface can be used to parse and/or 
retrieve elements or portions from the XML document in order to validate 
those elements or portions. Once the XML document is validated, it can 
be passed to the client application as a response document 308. 

A flowchart for such a method is shown in Figure 4. The request is 
received from the client application to an EIS 400. The EIS returns 
metadata in response to the request 402. The metadata is transformed 
into an XML document 404. At least portions of the XML document can be 
parsed or extracted, such as by using an IDocument interface, and can be 
compared to the XML schema for the client application in order to validate 
those portions 406. A determination is made as to whether each portion 
is valid 408. If each portion is valid, the validated XML document can be 
returned to the client as a response document 410. If each portion is not 
valid, a determination should be made whether the client application should 
receive invalid documents 412. If the client should receive an invalid 
document, each error can be logged 414 and the validated (or invalidated) 
XML document is passed to the client as a response document 410. 

If the client should not receive an invalid XML document, a 
determination should be made whether an end condition has been met 
416. An end condition can be set so that an infinite loop is not created if 
the metadata cannot be transformed into a valid XML document. "Valid" 
in this instance means that the XML document is valid against the XML 
schema, not that the document is a valid XML document. The client 
application may receive a document that conforms to the XML schema but 
that is not a proper XML document. If the end condition has not been met, 
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another attempt can be made to transform the metadata into an XML 
document 404. If the end condition has been met, such as a number of 
iterations or timeout period end being reached, an error can be returned to 
the client application and processing of this request can stop 418. 



An XML schema is like a contract between the EIS and an 
application on the other side of the adapter. This contract can specify how 
data coming from the EIS must appear in order for the application to 
manipulate it. A document, or an XML-rendered collection of metadata 
from an EIS, can be considered valid if it meets the mles specified in the 
schema, regardless of whether or not the XML is correct. For example, if 
a schema required a name to appear in a <name> element and that 
element required two child elements, such as <firstname> and <lastname>, 
to be valid, the document from the EIS would have to appear in a form 
such as: 

<name> 

<firstname>Joe</firstname> 

<lastname>Smith</lastname> 
</name> 



and the schema would have to appear in a form such as: 

<schema> 

<element name=-name"> 
<complexType> 
<sequence> 

<element name="fiirstname" /> 
<element name="lastname" /> 
</sequence> 
</complexType> 
</element> 
</schema> 



No other form of <name></name>, such as "<name>Joe Smith</name>" 
would be valid, even though the XML is correct. 
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Creating the Schema 

An XML schema can be created programmatically by using the 
classes and methods provided with SOfVI. One benefit of using such a tool 
is that it allows a user to tailor a schema for that user's needs simply by 
populating the variables in the program components. For instance, the 
following code examples create a schema that validates a purchase order 
document: 



import com.bea.schema.*; 

import com.bea.schema.type.SOIVIType; 

public class PurchaseOrder 
{ 

public static void main(StringD args) 
{ 

System.out.println(getSchema().toString()); 

} 



public static SOMSchema getSchema() 
{ 

SOI\/1Schema po_scliema = new SOIVISchema(); 

po_schema.addDocumentation("Purchase order sciiema for 
Example.comAnCopyright 2000 Exampie.comAnAII riglits 
reserved."); 

SOMEIement purchaseOrder = 
po_schema.addElementrpurchaseOrder"); 



SOMEIement comment = po_schema.addElement("comment"); 



SOMComplexType usAddress = 
po_schema.addComplexType("USAddress"); 

SOMSequence seq2 = usAddress.addSequence(); 
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// adding an object to a SOMSchema defaults to type-'string" 
seq2.addElement("name"); 
seq2,addElementrstreet"); 
seq2.addElement{"city"): 
5 seq2 .addElementfstate"); 

seq2.addElement("zip". SOMType.DECIMAL); 

One benefit to such a tool is that it is only necessary to populate the 
variables in the program components to tailor a schema for particular 
10 needs. Attributes can be set in the same way that elements are created, 

such as: 

SOMAttribute country_attr = 

usAddress.addAttrlbutefcountry", 
1 5 SOMType.NMTOKEN); 

country_attr.setUse("flxed"); 
country_attr.setValue("US"); 

To correctly set these attributes, their addressibility should be 
20 maintained. Like complexTypes. simpleTypes can be added to the root of 

the schema, such as: 

SOMSimpleType skuType = po_schema.addSimpleType("SKU"); 
SOMRestriction skuRestrict = skuType. add Restriction 
25 (SOMType.STRING); 

skuRestrict.setPattern("\\d{3}-[A-ZI{2n; 
SOMComplexType poType = 

po_schema,addComplexType("PurchaseOrderType"); 
purchaseOrder.setType(poType); 
30 poType.addAttributerorderDate**. SOMType.DATE); 

The addSequenceO method of a SOMComplexType object can 
return a SOMSequence reference, allowing a user to modify the element 
that was added to the element. In this way objects can be added to the 
35 schema, such as by implementing an addSequence() method to modify an 

element: 

SOMSequence poType_seq = poType.addSequence(); 



-25- 



wo 03/034228 



PCTAJS02/33090 



poType_seq.addElement("shipTo", usAddress); 
poType_seq.addElement("billTo", usAddress); 

Attributes of an element within a schema can be set by calling setter 
methods of a SOMEIement object. For example., an the implementation of 
setMinOccursO and setMaxOccurs() can be given by: 

SOMEIement commentRef = new SOMEIement(comment); 

commentRef.setMinOccurs(O); 

poType_seq.add(commentRef); 
SOMEIennent poTypeJtems = poType_seq.addElement("ltems"); 

SOMComplexType itemType = po_schema.addComplexType('*ltems"); 
SOMSequence seq3 = itemType.addSequence(); 
SOMEIement Item = new SOMEIement("item"); 

item.setMmOccurs(O); 

ltem.setMaxOccurs(-1 ); 

seq3.add(item); 
SOMComplexType t = new SOMComplexTypeO; 

ilem.setType(t); 
SOMSequence seq4 = t.addSequenceQ; 

seq4.addElement("productName"); 
SOMEIement quantity = seq4.addElement("quantity"); 
SOMSimpleType st = new SOMSimpleType(); 

quantity.setType(st); 
SOMRestriction restrict = 
st.addRestrictlon{SOMType.POSITIVEINTEGER); 
restrlct.setMaxExcluslve("1 00"); 

In this example, the items element for PurchaseOrderType was 
created before items type. The reference can be created and the type set 
once the Items type object is available, such as by using: 
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poTypeJtems.setType(ltemType); 



An element can also be added to the schema. Adding an element 
can be done by implementing an addElement() method of SOMSequence, 
or the add() method from a previously created SOM Element. These 
methods can be shown by: 

seq4.addElement("USPrice", SOMType.DECIMAL); 

SOMEIement commentRef2 = new SOMEIement(comment); 
commentRef2.setMinOccurs(0); 
seq4.add(commentRef2); 

SOMEIement shIpDate = new SOMEIementfshlpDate", SOMType.DATE); 

shipDate.setMinOccurs(O); 

seq4 .add($hipDate); 
t.addAttribute("partNum'\ skuType); 

return po_schema; 

} 

} 



When running the code shown in the previous examples, the 
following schema can be created: 



<?xml version="1 .0" ?> 

<!DOCTYPE schema (View Source for full doctype.,.)> 
<xsd:schema xmlns:xsd="http://www.w3.org/2000/XMLSchema"> 
<xsd:annotation> 

<xsd:documenlation>Purchase order schema for Example.com. 
Copyright 2000 Examp/e.com. All rights 
reserved . </xsd :docu mentation > 

</xsd:annotatlon> 

<xsd:simpleType name="SKU"> 

<xsd:annotation> 

</xsd:annotatjon> 

<xsd:restrictlon base=*'xsd:string"> 
<xsd:pattem value="\d{3)-[A-Z]{2}" /> 

</xsd:restrictlon> 
</xsd:simpleType> 

<xsd:complexType name="PurchaseOrderType"> 
<xsd:sequence> 
<xsd:element type="USAddress" name="shlpTo" /> 
<xsd:element type="USAddress" name="blllTo" /> 
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<xsd:element ref="commenf minOccurs="0" /> 
<xsd:element type="ltems" name="items" /> 
</xsd:sequence> 

<xsd:attribute name=''orderDate" typ8="xsd:date" /> 
</xsd :complexType> 

<xsd:complexType name="ltems"> 
<xsd:sequence> 

<xsd:element maxOccurs="unbounded" name="item" 
mjnOccurs="0"> 
<xsd rcomplexTy pe> 
<xsd:sequence> 
<xsd:element type="xsd:string" 

name="productName7> 
<xsd:element name="quantity"> 
<xsd:simpleType> 
<xsd: restriction base= 
"xsd:posltivelnleger"> 
<xsd:maxExclusive value="1007> 
</xsd:restnctjon> 
</xsd :simpleType> 
</xsd:element> 

<xsd:element type="xsd;decimar name= 

"USPrice"/> 
<xsd:elemenl ref="commenr 

minOccurs="0" /> 
<xsd:element type="xsd:date" 

name="shlpDate" minOccurs="0" /> 
</xsd:sequence> 

<xsd:attribute name="partNum" type="SKU" /> 
</xsd :compl exType> 
</xsd:element> 
</xsd:sequence> 
</xsd:complexType> 

<xsd:complexType name="USAddress"> 

<xsd:sequence> 

<xsd:element type="xsd:string" name="name" /> 
<xsd:element type="xsd:string" name="streer /> 
<xsd:element type="xsd:string" name="city" /> 
<xsd:element type="xsd:string" name="state" /> 
<xsd:element type="xsd:number name="zlp" /> 

</xsd:sequence> 

<xsd:attribute name="country" use="fixed" value="US" 
type="xsd:NMTOKEN" /> 
</xsd:complexType> 

<xsd:element type="PurchaseOrderType" name="purchaseOrder /> 
<xsd:element type="xsd:string" name="commenr /> 
</xsd:schema> 
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Validating an XML Document 

Once the schema is created, it can be used to validate a document 
sent from an EIS. SOM can be used to validate XML DOM documents by 
using a SOMSchema method such as lsVa!id(). SOMEIement can have a 
conresponding isValid() method for validating an element instead of the 
DOM document. The isValid() method can determine if 'document or 
•element' is valid, and if not, can compile a list of the errors. If the 
document is valid, isValid() can return 'true* and the list of errors can be 
empty. 

An IsValidO method can be implemented in a number of different 
ways, including the following ways: 

public boolean isVa(id(org.w3c.dom.Document doc, 

java.util.List errorList) 
public boolean isValid(IDocunnent doc, 

List errorList) 

In this example, "doc" refers to the document instance to be validated, and 
"errorList" refers to a list of errors found in the document and/or doc. 

The isValidO method can return a boolean value of 'true' if the 
document is valid with respect to this schema. If the document is not valid 
with respect to the schema, isValid() can return 'false* and the errorList can 
be populated. The errorList is a java.util.List for reporting errors found in 
the document, doc. The error list is cleared before validating the document. 
Therefore, the list implementation used must support the clear() method. 
If isValidO returns false, the error list is populated with a list of errors found 
during the validation procedure. The items in the list are instances of the 
class com.bea.schema,SOMValidationException. If isValid() returns true, 
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errorList is empty. The following shows an example of an isValid() 
implementation: 

SOMSchema schema = 

IDocument doc = DocumentFactory.createDocument 

(new FileReader(f)); 
java.utll.LinkedList errorList = new 

java.util.LinkedListO; 
boolean valid = schema.isVaiid(doc, errorList);... 
if (! validK 

System.oul.println("Document was invalid. 
Errors were:"); 

for (Iterator i = errorList, iterator; i.hasNext();) 

{ 

System.out.println(((SOIVIValidationException) 
i.next).toString()); 

} 

The foregoing description of preferred embodiments of the present 
invention has been provided for the purposes of illustration and description. 
It is not intended to be exhaustive or to limit the invention to the precise 
forms disclosed. Many modifications and variations will be apparent to one 
of ordinary skill in the art. The embodiments were chosen and described 
in order to best explain the principles of the invention and its practical 
application, thereby enabling others skilled in the art to understand the 
invention for various embodiments and with various modifications that are 
suited to the particular use contemplated. It is intended that the scope of 
the invention be defined by the following claims and their equivalence. 
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What is claimed is: 

1. A method for passing communication between an enterprise 
system and a client application, comprising: 

transforming metadata received from an enterprise system into an 
XML document; 

validating at least a portion of the XML document against an XML 
schema for the client application; and 

passing the XML document to the client application. 

2. A method according to claim 1 . further comprising: 
building the XML schema using an XML schema API. 

3. A method according to claim 1 , further comprising: 
building the XML schema using a schema object model. 

4. A method according to claim 3, wherein: 

building the XML schema further includes using classes and 
methods In the schema object model. 

5. A method according to claim 2, wherein: 

building the XML schema includes populating variables in program 
components of the schema object model in order to tailor the XML schema 
for the client application. 

6. A method according to claim 1 , further comprising: 
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creating a schema object model to validate an XML schema for the 
client application. 

7. A method according to claim 1 , wherein: 

compiling a list of errors containing elements of the XML document 
that are not valid. 

8. A method according to claim 1 , further comprising: 

translating information passing between the enterprise system and 
the client application using a resource adapter. 

9. A system for passing communication between an enterprise 
system and a client application, comprising: 

a resource adapter adapted to receive metadata from an enterprise 
system; and 

an XML schema component adapted to transform the metadata into 
an XML document and validate the XML document against an XML 
schema; 

wherein the resource adapter is further adapted to pass a validated 
XML document to the client application. 

10. A system according to claim 9, further comprising: 

a schema object model adapted to provide the ability to create the 
XML schema. 
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1 1 . A system according to claim 9, further comprising: 

an application view component adapted to provide an interface to 
the enterprise system for the client application. 

12. A computer-readable medium, comprising: 

means for transforming metadata received from an enterprise 
system into an XML document; 

means for validating at least a portion of the XML document against 
an XML schema for the client application; and 

means for passing the XML document to the client application. 

13. A computer program product for execution by a server computer 
for formatting enterprise data for an application, comprising: 

computer code for transforming metadata received from an 
enterprise system into an XML document; 

computer code for validating at least a portion of the XML document 
against an XML schema for the client application; and 

computer code for passing the XML document to the client 
application. 

14. A system for formatting enterprise data for an application, 
comprising: 

means for transforming metadata received from an enterprise 
system into an XML document; 

means for validating at least a portion of the XML document against 
an XML schema for the client application; and 
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means for passing the XML document to the client application. 

1 5. A computer system comprising: 
a processor; 

object code executed by said processor, said object code configured 

to: 

transform metadata received from an enterprise system into 
an XML document; 

validate at least a portion of the XML document against an 
XML schema for the client application; and 

pass the XML document to the client application. 

16. A computer data signal embodied in a transmission medium, 
comprising: 

a code segment including instructions to transform metadata 
received from an enterprise system into an XML document; 

a code segment including instructions to validate at least a portion 
of the XML document against an XML schema for the client application; 
and 

a code segment including instructions to pass the XML document 
to the client application. 

17. A method for passing communication between an enterprise 
system and a client application, comprising: 

transforming metadata received from an enterprise system into an 
XML document; 
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querying the XML document using a document interface component 
in order to extract at least a portion of the XML document; 

validating said at least a portion of the XML document against an 
XML schema for the client application; and 

passing the XML document to the client application. 

18. A method according to claim 17, further comprising: 
building the XML schema using an XML schema API. 

19. A method according to claim 17, further comprising: 
building the XML schema using a schema object model. 

20. A method according to claim 19, wherein: 

building the XML schema further includes using classes and 
methods In the schema object model. 

21 . A method according to claim 1 8, wherein: 

building the XML schema includes populating variables in program 
components of the schema object model in order to tailor the XML schema 
for the client application. 

22. A method according to claim 17, further comprising: 

creating a schema object model to validate an XML schema for the 
client application. 
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23. A method according to claim 17, wlierein: 

compiling a list of errors containing elements of the XML document 
that are not valid. 

24. A method according to claim 17, further comprising: 

translating information passing between the enterprise system and 
the client application using a resource adapter. 

25. A method for passing communication between an enterprise 
system and a client application, comprising: 

transforming metadata received from an enterprise system Into an 
XML document; 

querying a document interface component in order to validate at 
least a portion of the XML document against an XML schema; and 

passing the XML document to the client application. 

26. A system for passing communication between an enterprise 
system and a client application, comprising: 

a resource adapter adapted to receive metadata from an enterprise 
system in response to a request from a client application; 

a document interface component adapted to allow the querying of 
elements in an XML document; and 

an XML schema component adapted to transform the metadata into 
an XML document and validate elements the XML document against an 
XML schema, the XML schema component obtaining the elements through 
the document interface component; 
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wherein the resource adapter is further adapted to pass a validated 
XML document to the client application. 

27. A system according to claim 26, wherein: 

the document interface component is an XML document API. 

28. A system according to claim 26, wherein: 

the document interface component is adapted to work with DOM 
documents. 

29. A system according to claim 26. wherein: 

the document interface component provides an XPath interface to 
elements in an XML document. 

30. A system according to claim 26, wherein: 

the document interface component allows portions of an XML 
document to be queried and updated using XPath strings. 

31 . A system according to claim 26, wherein: 

the document interface component comprises a container including 
a DOM instance and an XPath interface. 

32. A system according to claim 26. wherein: 

the document Interface component is a public interface that 
represents an XML document. 
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33. A system according to claim 26, wherein: 

the document interface component allows manipulation of elements 
in an XML document, the manipulation selected from the group consisting 
of retrieving, modifying, adding, and removing data elements. 

34. A system according to claim 26, further comprising: 

a schema object model adapted to provide the ability to create the 
XML schema. 

35. A system according to claim 26, further comprising: 

an application view component adapted to provide an interface to 
the enterprise system for the client application. 

36. A computer-readable medium, comprising: 

means for transforming metadata received from an enterprise 
system into an XML document; 

means for querying the XML document using a document interface 
component in order to extract at least a portion of the XML document; 

means for validating said at least a portion of the XML document 
against an XML schema for the client application; and 

means for passing the XML document to the client application. 

37. A computer program product for execution by a server computer 
for formatting enterprise data for an application, comprising: 
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computer code for transforming metadata received from an 
enterprise system into an XML document; 

computer code for querying the XI\^L document using a document 
interface component in order to extract at least a portion of the XML 
document; 

computer code for validating said at least a portion of the XIVIL 
document against an XML schema for the client application; and 

computer code for passing the XML document to the client 
application. 

38. A system for formatting enterprise data for an application, 
comprising: 

means for transforming metadata received from an enterprise 
system into an XML document; 

means for querying the XML document using a document interface 
component in order to extract at least a portion of the XML document; 

means for validating said at least a portion of the XML document 
against an XML schema for the client application; and 

means for passing the XML document to the client application. 

39. A computer system comprising: 

a processor; object code executed by said processor, said object 
code configured to: 

transform metadata received from an enterprise system into 
an XML document; 
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query the XML document using a document interface 
component in order to extract at least a portion of the XML 
document; 

validate said at least a portion of the XML document against 
an XML schema for the client application; and 

pass the XML document to the client application. 

40. A computer data signal embodied in a transmission medium, 
comprising: 

a code segment including instructions to transform metadata 
received from an enterprise system into an XML document; 

a code segment including instructions to query the XML document 
using a document interface component in order to extract at least a portion 
of the XML document; 

a code segment including instructions to validate said at least a 
portion of the XML document against an XML schema for the client 
application; and 

a code segment including instructions to pass the XML document 
to the client application. 
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